Computer networks are subject to a variety of security breaches. One such type of breach occurs when a user or computer system falsely identifies itself, in order to access resources that it is not authorized to access, or to otherwise avoid being correctly associated with a request. To facilitate request authentication, a request for service directed to a party providing a resource or service, hereinafter referred to as a “relying party,” includes the identity of the requester in a manner such that the relying party can verify the authenticity of the identity. Request authentication is the process of verifying the identity of the sender of a request. Authentication provides some level of security that each party's identification is accurate. The identity of the requester forms the basis for access control decisions made by the relying party.
One type of request authentication includes the use of a username and password. A stronger type of authentication involves the use of a security token. Some types of security tokens are issued by a trusted identity provider. Possession of a security token serves to provide proof of identity for the possessing party. Some security tokens have embedded cryptographic keys for stronger security.
In one type of interaction, a requester acquires a security token from an identity provider. The requester then presents the security token with a service request to a party providing a resource or service. The resource provider has a trust relationship with the identity provider that serves as assurance of the authenticity of the security token.
WS-Trust is a specification of a framework for requesting and issuing security tokens. It describes a Security Token Service (STS) that performs actions of an identity provider. A version of the WS-Trust framework is available at http://docs.oasis-open.org/ws-sx/ws-trustt/v1.4/ws-trust.html.
In some situations, a request to an identity provider may fail. The requester may not be provided with sufficient information to determine the reason for the failure. In some situations, the identifying party may have made a correct decision to deny the request. In some situations, the identifying party may have failed due to an improper configuration or other error. A requester may not receive information sufficient to determine the reason for an error, and an administrator may not have sufficient information to troubleshoot the identifying party system.